當時有個新創公司的CTO，我問過他，你們的敏捷到底是怎麼跑起來的？

除了他，我們找過很多敏捷教練，教我們怎麼導入Sprint開發。該有的會議一個都沒少，Sprint Planning、Review、Retrospective、Standup，全部照表操課。但我們一次都沒有真正體會到敏捷的精神，跑的都是形式，Sprint重啟了三四次，卻沒有哪裡不一樣。

恩，我們那時想，一定是缺少好的工具，讓我們很好地追蹤估時、分解user story以及看burndown chart，如果要解決，就需要上Jira，把工程團隊常用的相關工具像是Confluence等都付費使用。

那位CTO說，工具從來不是重點。重點是，有沒有真的體驗到敏捷的文化，有沒有共同的目標、有沒有默契，大家是不是真的在協作，而不是各做各的，開會只是為了交差。

2021年8月，團隊經過一批人的離去與重整，要重新跑一次Sprint。新來的工程師夥伴理所當然地問，是不是該上Jira了？我這次沒有馬上答應，先用Google Sheet和Notion，想先確認我們是不是真的培養出那份默契，而不是急著把工具搬進來。我也花了更多時間釐清目的，而不是單純在運用工具、有體無魂的在開會。

工具沒有標準答案，只有自己怎麼運用、為何運用

後來我在工程團隊營運跟專案管理上，累積了不少年的經驗。總會有人問我，「PC，你有沒有推薦什麼好用的專案管理工具？」我的答案一直是同一句話，這其實是大部分人的迷思。重點從來不是用哪一套工具，是你今天怎麼運行這個專案。如果團隊本來就沒有共同的默契，沒辦法好好協作，換什麼工具都沒用。反過來說，就算只用便條紙，也可以做出很好的專案管理。

和AI協作也是同一回事，我還是常遇到有人問我，「要選擇哪一個AI好？」「要請AI用哪個工具解決問題才好？」，重點從來不是用哪個工具，是有沒有真的理解那件事背後的本質。學會100種prompt公式，但不了解prompt為什麼要這樣寫；知道許多AI衍生的名詞，但不了解這些名詞背後想要傳達的意義是什麼，都像是我們當初Sprint用了許多框架與工具，但都沒有真正體會Sprint最初的4大宗旨。

其實敏捷宣言就把這件事講得很清楚了，四大核心價值的第一條就是「個人與互動，重於流程與工具」。工具再新、框架再完整，都只是為了服務背後那個更根本的目的，不是拿來取代目的本身。當年我們捨本逐末，先追工具、後補理解，繞了一大圈才想通這件事；現在很多人學AI，也是同一個順序，先囤了滿手的AI小妙招，但卻沒有回頭問一句，自己到底想解決什麼問題。

理解夠了，才真的敢把事情交出去，不管是交給工程師，還是交給AI。但敢交出去，只是下一關的開始，接下來要面對的是，東西交回來之後，要怎麼判斷這個結果到底能不能用。